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ABSTRACT 


The Space Shuttle Main Engine (SSME) presented new requirements in the design of controls for 
large pump-fed liquid rocket engine systems. These requirements were the need for built-in full 
mission support capability, and complexity and flexibility of function not previously needed in this 
type of application. 

An engine mounted programmable digital control system was developed to meet these requirements. 
The engine system and controller and their function are described. Design challenges encountered 
during the course of development included accommodation for a very severe engine environment, the 
implementation of redundancy and redundancy management to provide fail -operational /fail -safe capabili- 
ty, removal of heat from the package, and significant constraints on computer memory size and process- 
ing time. 

The flexibility offered by programmable control reshaped the approach to engine design and devel- 
opment and set the pattern for future controls development in these types of applications. 


INTRODUCTION 


Development of controls for the Space Shuttle Main Engine (SSME) presented many new engineering 
challenges which had not been previously faced in the design of controls for large pump-fed liquid 
rocket engine systems. Notable among these challenges were: 

1. A requirement for built-in full mission support capability from the early checkout phases 
through main engine cutoff and propellant dump during flight. 

2. A need for flexibility and complexity of function not previously attained in any liquid rocket 
engine system. 

Most of these challenges were the direct result of a new orientation in control system require- 
ments for rocket engines brought about by the unique requirement of the Space Shuttle for a reusable 
and maintainable man-rated system. 

The following sections, review requirements and give a general description of the control system. 
Some of the major alternatives considered are discussed along with reasons for selecting the final 
configuration. Development problems are reviewed and development experience evaluated. 


DISCUSSION 


CONTROL SYSTEM REQUIREMENTS 

The SSME control system must support engine utilization during all phases of the mission sequence 
from checkout through propellant loading, liftoff, flight and shutdown in orbit. It is required to 
have the capability of self-contained checkout in the assembly area, and at the launch area prior to 
flight. The control system must also support engine start preparations, provide repeatable start, 
mainstage control , and shutdown upon vehicle command. In addition, it must have the ability to monitor 
engine critical operating parameters (redlines), provide fault detection, manage redundancy and report 
engine status conditions during all phases of operation. 
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The control system is required to vary engine thrust upon vehicle command between 65 and 1 09% of 
Rated Power Level in 1% increments while maintaining mixture ratio within specification. Rated Power 
Level (RPL) is 100%, while Full Power Level (FPL) at 109% can be commanded when vehicle conditions 
require it. 

Required thrust precision is +-6000 lb (3 sigma) during steady-state operation. Thrust must be 
within steady-state limits within 1 second after a commanded change without rate of change exceeding 
7000 lb/10 ms. Mixture ratio accuracy is required to be within +-1%. The engine must be capable of 
accelerating from start signal to RPL in 3.9 seconds with mixture ratio within tolerance in less 
than 5.5 seconds. 

Requirements include on-board checkout capability, redundancy verification, and status monitoring 
for systems verification during ground and flight operations. Rapid fault isolation techniques are 
required which activate or deactivate redundant components without unduly disturbing engine operation. 
The control system is also required to provide automatic checkout of engine functional components with 
fault isolation to Line Replaceable Units (LRU) during ground checkout to minimize vehicle turnaround 
time, and to be capable of subsystem replacement without engine recalibration. 

All critical electrical elements of the control system must be redundant for a fail -operational/ 
fail-safe design. 


ENGINE AND CONTROL SYSTEM DESCRIPTION 

The SSME is a reusable, high performance, Liquid Hydrogen/Oxygen , rocket engine designed and 
produced by the Rocketdyne Division of Rockwell International under contract with Marshall Space 
Flight Center. It has four turbopumps (two low-pressure and two high-pressure) , two preburners, 
a main combustion chamber, five hydraul i cal ly actuated propellant control valves, sensors, and an 
engine mounted electronic digital controller. The staged-combustion cycle burns low mixture ratio 
propellants in the preburners first. These fuel-rich gases are used to drive the high-pressure 
turbopumps and are then routed to the main combustion chamber where they are burned with additional 
oxidizer to obtain maximum performance. 

Performance control is closed-loop feedback control with full authority over the engine operating 
range. The control block diagram is illustrated in Fig. 1. Thrust and mixture ratio control are 
provided by adjusting the power to the two high-pressure turbopump turbines through control of the 
oxidizer flow to the preburners with modulating preburner oxidizer valves. Thrust control is 
provided by modulation of the oxidizer preburner oxidizer valve, and mixture ratio control is 
accomplished by modulation of the fuel preburner valve. Cross-feed compensation from the oxidizer 
preburner valve command to the fuel preburner valve is used to minimize the effects of thrust 
transient changes on engine mixture ratio. In addition to the two preburner valves used in perfor- 
mance control, three other propellant valves are scheduled to initiate propellant flow during start 
and to assist in control of shutdown. In addition the chamber coolant valve is scheduled as a 
function of thrust to prevent overheating in the nozzle and combustion cooling circuit as the engine 
is throttled. More detailed descriptions of the control logic and hardware are contained in 
Ref. 1 and 2. 

The controller, which was designed and manufactured by Honeywell, Incorporated, is mounted on the 
side of the main combustion chamber. It is a single, integral electronics package containing dual 
programmable digital computers, each with 16384 words of memory. The Honeywell HDC-601 digital 
computer with 2 mil plated wire memory is used in the controller. Input electronics, computers, power 
supplies, and output electronics are dual redundant. Fig. 2, with cross-strapping at the input and 
output of the computer electronics. Installation characteristics are listed in table 1. The 
controller interfaces (Fig. 3) with 67 sensor inputs and 43 output device channels. Controller to 
vehicle interfaces include 3 redundant vehicle command channels, 2 status recorder output channels, 

2 redundant power channels, and a 28 vdc input for heater operation in orbit. The status recorder 
channels transmit 128 data words every 40 milliseconds to the vehicle data bus. 
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DESIGN ALTERNATIVES AND DEVELOPMENT CONSIDERATIONS 


Controller Location and Mounting 

Both mechanical and electrical problems were experienced during the design and development. 

Early studies clearly showed the controller should be engine mounted to provide an integral complete 
engine system and to avoid routing in excess of four hundred wires across the gimballed engine 
interface. Presently there are a total of twenty three wires across the interface for power, 
commands, memory loading, status data, controller heater power, and analog temperature measurement. 

The controller was initially designed to be hard mounted vertically against the thrust chamber 
with a reguirement to meet a 22.5 grms vibration environment. This was a very severe constraint on 
controller mechanical design so the controller mounting was subseguently changed to use rubber inserts 
which reduced the vibration environment to approximately 4 grms. 


Digital Versus Analog and Hardware Software Partitioning 

Although the selection of digital versus analog implementation of control logic would be heavily 
weighted in favor of programmable digital today, the case was not so clear-cut in 1970 when decisions 
of this nature were being made. However, the complexity of functions and need for ease of change in 
logic during the early phases of engine development weighted the decision towards digital programmable 
controls. The valve positioning curves of Fig. 4 are an illustration of the case in point. All five 
engine propellant valves are commanded to multiple positions during the start seguence. Up to seven 
different positions and rates are commanded to each propellant valve during the 3.9 second engine 
start seguence. The parameters for these valve positioning commands were changed many times during 
the engine development program in order to obtain the desired start characteristics. 

Complexity and immaturity of the control algorithms and checkout functions also reguired the 
flexibility of a programmable system. In addition, calibration factors unigue to each engine were 
reguired to be stored and utilized by the controller. 


Packaging and Heat Removal 

The controller electronics are mounted on conventional printed circuit cards. The printed 
circuit cards are retained in the controller chassis by a rigid foam packaging system which further 
isolates the electronics from the vibro-acoustic environment of the engine. In this packaging 
system, the chassis is divided into cavities, each of which accepts two cards. Each card has an open 
foam grid attached to the component mounting side and a foam half-wedge attached to the back side. 

The cards are retained in the chassis cavity by loading a foam wedge between the two cards. This 
provides for very tight card retention as well as isolation from vibration transmitted through the 
chassis and it detunes the printed circuit card/chassis structure system. This protected the modules 
from vibration but created a problem i r. dissipating the heat from the cards. A design change 
was made so that the foam grids, which are in contact with both the printed circuit cards and chassis 
walls, have an aluminum foil surface which provides heat transfer from the electronic parts. 

Cooling is accomplished by conductive heat transfer through the chassis and convection heat transfer 
from the chassis surface to the atmosphere. Additional chassis surface area is obtained by extensive 
use of pin fins machined into the chassis. 


Electrical and Memory Problems 


Other notable problems were the memory system and power supply. Plated wire was selected for the 
memory based on speed, power, non-volatility, and non-destructive readout. At the time of design, 
five mil diameter wire was being used on several programs. However, two mil wire was selected for 
the controller to reduce size and power. Many problems were encountered in the development of the 
memory system until a "coupled film" plating was developed and used on both the SSME and Viking 
programs. 
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Input power to the controller was selected to be 115 volt, 400 Hz three-phase in preference to 
28 vdc. A small transformer on the input provides power for operating the power supply. The primary 
load is three-phase full -wave rectified resulting in 270 vdc to be switched by the switching regulator. 
Potential faults on the input bus from other users resulted in a requirement to be able to operate 
down to 95 volts rms for up to one second. A boost stage regulator was employed to accommodate this 
requirement. A problem of high current demand of engine solenoid loads during power recovery and 
engine start operation was solved by dividing the solenoids into banks. The biggest problem of all 
in the power supply was packaging the unit in the space available. 


Software Design 

Software program organization as it finally evolved is illustrated in Fig. 5 . Because of computer 
memory size constraints three types of program configurations are resident in memory at different 
times depending upon the phase of mission operations. Changes in configuration are accomplished by 
use of "roll-in" modules of code which overlay pre-existing code and change controller function. All 
coding is in DAP-16 assembly language. 

The ground checkout configuration is used during component checkouts. This configuration has five 
sub-configurations, each designed to facilitate automated checkout of different elements of the 
engine and controller such as actuators, pneumatic solenoid valves, sensors, ignitors and redundancy. 

The flight readiness test (FRT) configuration is used to perform an extensive system test of the 
engine and controller without initiating powered operation of the engine. This test configuration 
includes a simplified digital dynamic model of the engine which produces simulated pressures, tempera- 
tures and flows in response to measured engine valve positions. These simulated parameter values are 
substituted for actual sensor readings and used by the controller to "run" the engine with the same 
logic as used in powered operation during flight. 

The flight configuration is used for engine start preparation, start, and all flight operational 
phases. 

Dominant constraints on software design were process time and memory size. Dynamic simulation 
studies of the engine system early in the program demonstrated that a major cycle (control iteration) 
time of .02 seconds or less was necessary in order to provide adequate control response capability in 
the event of certain types of oxidizer preburner oxidizer valve actuator failures. Worst case major 
computation cycle time grew rapidly in the early years of the program, reaching .018 seconds in the 
first few years. An on-going effort was necessary to hold the line on this parameter. 

Program size grew much faster and larger than ever seemed reasonable to anticipate given the 
requirements as they were understood at the beginning of the project. At the very beginning it 
was estimated that 8000 words would be sufficient for all program requirements, so 12000 words 
memory capacity was proposed. Requirements to vote variable commands from the orbiter with software 
rather than hardware, requirements to do an FRT, and other changes necessitated expanding the memory 
to 16000 words. Fig. 6 documents memory requirement estimates over the 11 year life of the program. 

Early phases of program size growth were, to a great extent, the result of maturing of system 
requirements as detailed engine hardware design and development progressed. Program size initially 
grew rapidly as the complexity of checkout requirements increased. This early rapid growth resulted 
in a decision in mid-1973 to separate checkout functions from the flight portion of the program and 
to implement the roll-in module concept. The roll-in concept was further implemented late in 1974 
with the conversion of the sample problem element of the software to a roll-in module. 

Since 1976 there has been a continuous effort to work within the memory size constraint. Design 
scrubs are necessary in order to allow implementation of new requirements. In the course of develop- 
ment 12 major software program versions have been issued with many more interim revisions. Maximum 
resident code today is 15696 16 bit plus parity words. Total program code including roll-in modules 
is 23349 words. Over 200,000 words of code have been implemented or rearranged in the course of the 
software effort. 

A more detailed discussion of avionics software development is presented in Ref. 3. 
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Control System Integration 


The SSME control system is a complex hardware/software system. Extensive analysis and testing 
was necessary to develop and verify the control system hardware/software implementation. Detailed 
digital and analog modeling studies were performed at Rocketdyne to characterize engine control 
characteristics. These studies were extended at Honeywell in detailing the controller design. 
Extensive simulation testing of the control system was performed at Honeywell using an analog model 
of the engine and a Command and Data Simulator to simulate the orbiter interface. More recently the 
majority of the control system testing has been accomplished at the Huntsville Simulation Laboratory 
(Ref. 4). This laboratory employs actual flight configuration control system hardware (controller, 
sensors, actuators, etc.) interfaced to a hybrid analog/digital real-time engine system simulator. 

The Simulation Laboratory provides a high fidelity test bed which allowed detailed integration 
testing of the control system prior to use in actual SSME test firings. Since the initiation of 
engine test firings, the Simulation Laboratory has continued to be extensively used for software 
verification and engine test support and more recently for flight support. 


EVALUATION OF DEVELOPMENT EXPERIENCE 

The SSME Digital Control System has been utilized for all engine test firings. As of this 
writing, 40 different SSME's have accumulated a total of tfver 1000 test firings, including 6 orbital 
flights, and over 50 hours of powered operation. 

As the SSME system has matured through this program, many control system requirement additions 
and changes have been made. The flexibility provided by use of a fully programmable digital computer 

has allowed the majority of these changes to be accomplished by software modification. This has 

facilitated rapid change incorporation and verification (through use of the Simulation Laboratory) 
with only minor perturbation to engine test schedules. 

Development of the SSME would not have been possible in a practical sense without the use of 
programmable digital control. Even though the introduction of operational software added a signifi- 
cant new cost element to rocket engine development, and cost saving benefits far outweighed the 
software costs. The very flexibility offered by programmable control, from the beginning of the 
program reshaped the approach to engine design and development. It is unlikely any pump- fed throttle 
able and reusable liquid rocket engine of the future will be designed without this approach. 

The importance of good simulation of the engine system, fault insertion capability, the use of 

prototype hardware which can be easily modified, and the capability for memory history tracking 
cannot be over emphasized. These capabilities will be essential to cost effective and timely develop 
ment of any future system of this nature. 

There is never enough memory or, conversely, the program always expands to fill the space avail- 
able. This situation is not necessarily bad. As the hardware aspects of a program mature the 
number of practical options to fix problems diminish. Software, as it matures, still retains the 
ability to absorb small changes on a short turn-around time basis. This factor should be given more 
weight at the beginning of a program. In the case of the SSME the nearly 300 percent increase in 
program size from original estimates was largely the result of immaturity of system requirements 
at the program onset. Unless the software requirements are well defined and mature from prototype 
system testing, program size estimate increases of 100 to 200 percent should not be surprising. 

The existing controller program is, of necessity, in assembly language because of processing 
speed and memory size limitations. Recent developments in microprocessors and memories have made 
practical significantly faster processing speeds and greater memory capacity at no expense in size 
or power relative to the existing controller. If software requirements can be maintained within 
bounds these increased capacities may enable the use of higher order languages in future engine 
controllers, thus reducing the cost of producing software and increasing its reliability. 
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CONCLUSIONS 


The requirements for the Space Shuttle Main Engine dictated a control system design that was 
unique to large pump-fed rocket engines. The digital programmable ful 1 -authority control implemented 
has demonstrated its ability to meet or exceed all mission requirements. The very flexibility offered 
by programmable control reshaped the approach to engine design and development. The success and 
benefits of this approach, demonstrated with the Shuttle Main Engines, have set the pattern for the 
future in development of controls for this type of application. 
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TABLE 1 CONTROLLER INSTALLATION CHARACTERISTICS 


SIZE 


23.5 X 14.5 X 17.0 INCHES 


WEIGHT 


211 POUNDS 


INPUT POWER 


490 WATTS (STANDBY) 
600 WATTS (MAINSTAGE) 


HEAT TRANSFER 


FORCED AIR COOLING (GROUND) 
CONVECTIVE COOLING (FLIGHT) 


MOUNTING 


FOUR POINT VIBRATION ISOLATORS 


VIBRATION 

ENVIRONMENT 


SINE 

RANDOM 


24 G’s PEAK 
22.5 G’s RMS 


TEMPERATURE 

ENVIRONMENT 


OPERATIONAL -50 TO +95F 

NON-OPERATION AL -200 TO +200F 
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FIGURE 1 PERFORMANCE CONTROL DIAGRAM 



FIGURE 2 SIMPLIFIED REDUNDANCY DIAGRAM 
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FIGURE 3 CONTROLLER INTERFACES 
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PROGRAM SIZE - THOUSAND OP WORDS 
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FIGURE 5 SOFTWARE PROGRAM COMPONENTS AND CONFIGURATIONS 
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FIGURE 6 CONTROLLER MEMORY REQUIREMENT ESTIMATES 
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